-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std
: add generic date.Date
, time.Time
, and date_time.DateTime
#19549
Conversation
I just now read #18272 (comment) and would like to give an argument in favor of this change: Date APIs are necessary for converting epoch timestamps to calendar dates and back. In addition to retrieving epoch seconds from a clock, the standard C library provides a Zig is also already using 3 different versions of |
std.date.Time
, std.time.Time
, and std.date_time.DateTime
std.date.Time
, std.time.Time
, and std.date_time.DateTime
std
: add generic date.Time
, time.Time
, and date_time.DateTime
The user would not need to bring their own time zone database (unless they are doing embedded development, in which case, they should be aware of the implementation details and bring their own), the OS does this. See #8396 (comment). |
68ee44b
to
25dbcb5
Compare
453b1e2
to
2de02e4
Compare
std
: add generic date.Time
, time.Time
, and date_time.DateTime
std
: add generic date.Date
, time.Time
, and date_time.DateTime
Now that RFC3339 parsing/formatting is removed, does it still satisfy the needs described here? By the way, I don't see any problems down the line if |
Yes, it still satisfies the needs. The offset was added to aid the UEFI implementation, but that implementation can simply add the offset. The RFC 3339 implementation was just something I thought was nice to have and easy to add. |
/// Allows leap seconds. | ||
second: Second = 0, | ||
/// Milliseconds, microseconds, or nanoseconds. | ||
subsecond: Subsecond = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the justification for this additional complexity over always using nanoseconds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saving bytes and allowing finer precision than nanoseconds.
It's the same argument for templating the Year
in Date
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are the sizes:
comptime {
assert(@sizeOf(Time(0)) == 3);
assert(@sizeOf(Time(3)) == 6);
assert(@sizeOf(Time(6)) == 8);
assert(@sizeOf(Time(9)) == 8);
}
If you think that calling Time(precision)
is cumbersome I can rename Time
-> TimeAdvanced
and then write:
/// Time with second resolution
pub const Time = TimeAdvanced(0);
/// Time with millisecond resolution
pub const TimeMillis = TimeAdvanced(3);
/// Time with microsecond precision.
/// Note: This is the same size `TimeNano`. If you want the extra precision use that instead.
pub const TimeMicro = TimeAdvanced(6
/// Time with nanosecond resolution
pub const TimeNanos = TimeAdvanced(9);
This would be more consistent with the default Date
and DateTime
types.
Edit: I talked myself into this. Let me know what you think.
The CI might get fixed by rebasing on master. |
6af17cc
to
cd88d7b
Compare
65409ed
to
f6ae391
Compare
The proposal this implements is not accepted. I suggest to maintain a third party date/time Zig package, and then at some point you can suggest to upstream it if you wish. |
A public (albeit inconvenient) implementation of Lines 42 to 186 in 12191c8
I believe this PR creates one obvious way of using I consider this an incremental improvement to the existing Moving forwardIf you believe this change goes too far beyond status quo I'm happy to leave #8396 open and remove the following:
Those changes will likely make this PR a net negative in terms of LOC and offer no additional functionality than what's already in |
Necessary for DER parser upgrade. New types convert from Date/Time <-> epoch seconds. Old types only converted from epoch seconds -> Date.
f6ae391
to
261a839
Compare
It's with great sorrow I publish yet another datetime library. I really hope the stdlib will have general purpose date and time parsing upon 1.0.0. |
Add
Date
,Time
, andDateTime
structs with functions to convert to/from epoch subseconds and to add durations to them.These types are based off generic types which let the user make their own tradeoffs between memory and precision.
std.Date
, a Gregorian calendar date based off the Unix epoch.toEpoch
andfromEpoch
implemented using state of the art Euclidean Affine Functions (EAFs) by Neri and Schneider.std.date.gregorian.Date(YearType, epoch_days_since_1970_01_01)
.std.Time
, a time with second resolution.std.time.TimeAdvanced(precision)
.std.DateTime
which contains astd.Date
andstd.Time
.DateTime
types in status quo.aro/Compilation.zig
Potential future work:
/etc/localtime
on Linux/OSX. UseGetTimeZoneInformation
on Windows.Closes #8396.
Prior art #18272.